fix(app-shell): a failed package lookup is not an empty result (objectui#7881) - #7906

Fixes #7881

The defect

fetchFullPackage — the PackageSwitcher helper behind "Package info & settings" —
fetched /api/v1/packages and went straight to res.json(), never reading res.ok.

The platform answers a failed read in the ADR-0112 envelope,
{ success: false, error: { code, message } }, and that envelope parses cleanly
through the reader below it: root becomes the error object, which is neither an array
nor carries packages, so the list fell to [] and .find() to null. Nothing threw,
so openManage's catch — the one that toasts formatMetadataError — never ran, and
the two lines after it still fired: setManage(null) then setManageOpen(true).

PackageDetailSheet starts with if (!pkg) return null, so during an outage the author
clicked the menu item and got silence: no sheet, no toast, no explanation — and
manageOpen stuck true with no rendered sheet to close it.

Third variant of the objectui#7368 family after objectui#7821 (landed as #7879): not a
lost toast and not an inverted decision, but a failure laundered into a
successful-looking empty result. An empty list is a completely legitimate success
answer, which is exactly why it must never be the value a failure produces.

What was measured before deciding what to read

GET /api/v1/packages is served by the direct-mount registrar
(@objectstack/rest package-routes.ts), which mounts first in the production stack
and is pinned by check:route-envelope at zero hand-written bodies — every failure
leaves through the shared sendError / sendThrownError. Reachable on this path:

All four carry one shape, pinned wire-side by package-envelope.conformance.test.ts
(body.success === false, error an object, error.code a registered code,
error.message a non-empty string).

So the envelope's own success is not a second bit here. sendOk writes true on
every 2xx and the error writers write false on every non-2xx, which makes it !res.ok
restated — reading it as a second decision input would be a tolerant path for a shape
this seam cannot produce. res.ok is the decision; the envelope is read for the
words. In the 5xx band the platform withholds the producer's prose and substitutes
the generic Internal server error (INTERNAL_ERROR_MESSAGE), leaving error.code as
the only discriminating word — which is why the code travels with the message.

A second response shape exists and is reported here as asked: a non-JSON error body,
i.e. a proxy's HTML 502/504. That is the one arm the pre-fix code already reached the
catch on — by way of res.json() rejecting — and it showed the author
Unexpected token '<'. Covered: the tolerant read names the status instead. No third
shape was found on this path.

The fix

1. res.ok is read, and a non-2xx throws carrying the server's own error.message
   plus error.code, or HTTP nnn when the body is not the envelope at all.
2. Reported through this file's existing posture, not a second one —
   formatMetadataError on the shared studio-package-list sonner id, so one outage
   across this surface's four callers of that endpoint is one toast, not four.
   No new state machine, no new slot, no new channel.
3. The sheet no longer opens on a null package — this card's user-visible
   deliverable. A successful list that simply does not contain the package (deleted or
   uninstalled elsewhere) now says so through the same channel rather than opening over
   nothing.

One deliberate deviation, flagged for review

The failure is not also recorded in pkgsErr. That slot is the switcher list's
state and is written exactly where pkgs is — the mount effect and onManageChanged.
openManage never writes pkgs, so the names in the trigger are precisely as current as
they were a moment ago, and marking the trigger failed would say otherwise. The two
sibling fetchPackages call sites that likewise do not write the list (the writability
courtesy gate, the namespace lookup) report the same way — shared toast id, no slot
write. Say the word if the dispatch intended the slot write too.

Evidence — the ablation

Mutation leg: the source file put back to its pre-fix state (origin/main
d9580f464), the new pins kept.

• mutation proved on disk before any reading — HEAD blob deba94ef vs on-disk
  781e0c89, and the anchors flipped: if (!res.ok) 2 to 1,
  setManage(await fetchFullPackage(id)); 0 to 1, manageMissing 1 to 0.
• No rebuild leg applies: the pins import ./StudioDesignSurface by relative
  specifier, so vitest transforms the .tsx source directly and no dist/ stands
  between the mutation and the run.

Tests  6 failed | 8 passed (14)

⭐ 6 red, and the 3 negative controls green — plus all 5 of #7879's pins in the same
run. That last clause is what proves the new pins are not restating an existing
assertion, and that a "fix" which merely stopped opening the sheet could not pass this
file.

The reds are the defect itself, verbatim from the log:

• data-managed-id="" on four of them — the sheet opened on a null package;
• AssertionError: expected "vi.fn()" to be called at least once — openManage's
  catch never ran, nothing was reported at all;
• the non-JSON arm asserted to be 'HTTP 502' and got the pre-fix answer instead: a
  SyntaxError reading "Unexpected token", naming the opening angle bracket of the
  proxy's HTML error page. That is what the author used to be shown.

Restore leg proved by state, never by an exit code: on-disk blob back to
deba94ef = the HEAD blob, git diff HEAD --name-only empty, anchors back to
2 / 0 / 1. The script carried a trap ... EXIT INT TERM restoring an absolute
path, and the restore named HEAD explicitly (a bare git checkout -- path restores
from the index, which git checkout ref -- path had just written with the mutation).

Verification — all on the pushed commit c2c0f04f8, git diff HEAD empty

The type-check green is not vacuous: tsc -p tsconfig.test.json --listFiles lists all
three edited/added files (1 hit each), so the program really contains them.

Lint — a measured narrowing, not a skip

The repo-wide scan is CI's run. What was measured here instead:

• Population read from eslint itself, not guessed: eslint . over the whole affected
  package linted 1079 files (count from --format json), 0 errors.
• The 3 changed files on their own: 0 errors. The 19 warnings on StudioDesignSurface.tsx
  are all pre-existing — they sit at lines 691-4211, and every line this PR adds is in
  363-460.
• Config invariance for untouched files: eslint.config.js extends
  tseslint.configs.recommended with languageOptions: { ecmaVersion, globals } and
  declares no parserOptions.project and no projectService — type-aware linting is
  not enabled, so every rule's verdict is a function of that file's own text plus the
  shared config. A diff confined to three files cannot move any untouched file's verdict.

Boundaries held

• The hard-coded /home recovery destination is not touched — that belongs to
  objectui#7373, which stays open.
• onManageChanged is byte-for-byte unchanged — fix(app-shell): a failed package-list refresh is not a deletion (objectui#7821) #7879 just repaired it.
• The hand-rolled fetch is deliberately kept: retiring it in favour of the
  packages-io reader is the card's option 3, and it cannot reuse fetchPackages
  as-is because parsePackages trims the record this sheet needs. Out of scope here.
• Clause-② holds: no export added, no signature changed, no gate touched.

Generated by Claude Code